1. Prior Art
1.1 BSDL Language
For the sake of simplicity and clarity, a detailed description is given here below solely of the prior art pertaining to the use of BSDL language to describe the syntax of a bitstream.
Referring to FIG. 1, an example is recalled of the use of BSDL language to generate an adapted bitstream 12 from a source bitstream 11.
To this end, as indicated here above, the BSDL defines an XML syntax to describe the syntax of a bitstream compliant with a given format. This description is called a “Bitstream Syntax Description” or BSD.
More specifically, the description file for the source bitstream 11, referenced source BSD 14, is obtained by using a first processor 13, called BintoBSD used to parse the source bitstream 11 and instantiate its description.
The XML description file for the source bitstream is then converted into another XML description file, called a converted BSD 17, by using the XSLT (extensible Style sheet Language Transformation) language 16.
The adapted bitstream 12 is then obtained by using a second processor 18 called a BSD to Bin enabling the transformed BSD description 17 to be read and the corresponding adapted bitstream 12 to be generated.
To this end, these two processors BintoBSD 13 and BSD to Bin 18 use a XML document called a “Bitstream Syntax Schema” or BS Schema 15 which defines the structure of the given format and the types of fields defined by this format.
A more precise description is given here below of the working of the first BintoBSD processor 13 enabling the reading of a bitstream and the generation of its BSD description file.
It can be recalled especially that this process is gradual. This means that a current point of the bitstream (in other words at an instant t in the reading of the bitstream), all the fields already read are described by the partially instantiated BSD description file.
Here below in the document, the term “downstream” refers to that part of the bitstream that has already been read (and therefore already described in the partially instantiated BSD description) and the term “upstream” refers to the part that has not yet been read.
More specifically, during the bitstream reading process, it is common for the type, the number of occurrences and/or the size of a field of the bitstream, inter alia, to be determined by the value of another field present downstream or upstream in the bitstream.
According to the prior art, the BSDL language defines two ways of referencing a field of this kind depending on whether it is located downstream or upstream to the current position in the bitstream.    1. When a field of this kind is situated downstream from the current field, it has already been read and the value of this downstream field is therefore present in the partially instantiated BSD description file. The BSDL language is therefore used to reference an XML element corresponding to this field. To this end, BSDL uses the XPath language as described in a recommendation of the W3C dated November 1999 (XML Path Language, Version 1.0, W3C Recommendation 16, available on the Internet site http://www.w3.org/TR/xpath), and more specifically the path for locating the XML element corresponding to this field. It may be recalled that the XPath language is an expression language enabling the specification of an expression that brings into play arithmetic and logic operators, functions, constants, variables and location paths. A location path referenced “LocationPath”, thus enables the location of a set of nodes such as elements and attributes in an XML document. Thus, when a path of this kind is situated downstream from the current field, BSDL uses the XPath location paths to reference an element in the partially instantiated BSD.    2. When a field of this kind is located upstream to the current field, it is not yet present in the partially instantiated BSD description file. The field is then referenced by its location in bitstream. It may be recalled that, in this case, the field present upstream is generally situated in the vicinity of the current position in the bitstream, and is therefore present in the read buffer.
The BSDL language then makes it possible to specify several types of use of a field depending on whether it is situated upstream or downstream relative to the current position of the reading of the bitstream.
For example, the BSDL enables the value of a downstream field to be used in order to specify especially:                the number of occurrences of an element corresponding to a field to be read, which corresponds to the number of times that this field must be read in the bitstream;        the size of a field to be read;        the type of a field to read;        etc.        
To this end, BSDL uses the XPath expression which can include a reference to one or more fields situated downstream through their location path. This XPath expression is assessed with reference to the elements created in the partial BSD and its evaluation can, as the case may be, give a Boolean value (true or false), or an integer.
When the field is upstream, the possibilities of use are on the contrary far smaller in these prior art techniques As it happens, BSDL uses the upstream field only to decide on whether or not to instantiate an element. Thus, the attribute bs2: if Next applied to the declaration of an element in the XML document “BS Schema” (15), possibly combined with the attributes bs2: lookAhead and bs2: iNextMask, specifies that the element to which the attribute refers is instantiated if and only if the upstream field has a predetermined value.
1.2 Drawbacks of the Prior Art
Unfortunately, the technique currently used for the instantiation of a description file for a bitstream suffers from two main drawbacks.
Thus, for the use of fields of the bitstream situated downstream from a current position during the reading of the stream, the BSDL language relies on the use of the Xpath location path to reference these fields, as described here above. Now, to be able to assess this XPath location field, the BintoBSD processor 13 must store the partially instantiated BSD description file in its memory. Now, it must be noted that the size of this description file increases during the reading of the bitstream.
One major drawback of this prior art technique for the downstream fields therefore comes from memory consumption which may become prohibitive when the bitstream is big and especially so when the bitstream is generated continuously. This is the case for example in a continuously encoded video program (video encoded on the fly).
Indeed, the high consumption of memory resources may especially cause deterioration in the performance of the instantiation technique, or even cause it to fail.
Furthermore, for the use of fields of the bitstream situated upstream relative to a current position during the reading of the stream, the BSDL language limits the use of these fields to a test on the instantiation of the element.
One major drawback of this prior art technique for downstream fields is that they do not take account of the characteristics of the field to be read, for example its size, determined by a upstream field. It is indeed not possible to specify these characteristics with the BSDL language in this prior art technique.
1.3 Alternative Prior Art Approaches
To overcome the drawback related to high memory consumption in the storage of the partial BSD for downstream fields, one alternative solution has been proposed by the University of Ghent in the contribution MPEG M12217 (ISO/IEC JTC1/SC29/WG11 MPEG2005/M12217, “Context-related attributes for MPEG-21 BSDL”, Davy De Schrijver, Wesley De Neve, and Rik Van de Walle, July 2005, Poznan, Poland).
This approach can be used especially to memorize only one part of the BSD description file needed to assess XPath expressions.
However, this approach has many drawbacks.
Thus, this prior art solution always requires that a part of the BSD be saved (in practice, classically, a sub-tree). This consumes memory unnecessarily whereas only the values of some elements of this sub-tree are used by the XPath expression.
Furthermore, the downstream fields are always referenced by an XPath location path, the evaluation of which uses computation resources.
Finally, this prior art technique cannot be used to cope with the drawbacks related to the limitation of the use of the fields situated upstream with respect to a test on the instantiation of the element.